Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

REPL result formatting ambiguously renders scalars and sequences with square brackets

Aperta
  • Qualcosa non va?
#1,575 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, jupyter
Ambito
cli

Direzione di ricerca

Start by locating the REPL/Jupyter result-formatting entry point; the issue does not name a source file or test. Compare how add(2, 2), 2+2, and (1, 2) are rendered, then check whether existing tests cover scalar and sequence results. Done means the output distinguishes the explicitly scalar result from the sequence, or documents the display notation and explains the difference described in the issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

question

Summary

The REPL/Jupyter output uses square brackets for both a scalar calculation call and a sequence result. This makes the displayed values ambiguous as SysML values: a scalar Integer calculation appears as [4], while a sequence written with parenthesized comma syntax appears as [1, 2]. By contrast, ordinary arithmetic is displayed as an unbracketed scalar (4).

Reproduction

Observed with OpenSysML 0.11.0 using the SysML v2 (OpenSysML 0.11 experiment) Jupyter kernel:

private import ScalarValues::*;
calc add { in x : Integer; in y : Integer; return : Integer; x + y }
add(2, 2)

The call evaluates to:

✓ add(2, 2)
  = [4]

The declaration explicitly types both inputs and the return value as Integer. For comparison, 2+2 displays as = 4, while (2 + 2) also displays as = 4.

A sequence expression:

(1, 2)

is displayed as:

✓ (1, 2)
  = [1, 2]

Why this is confusing

In KerML textual syntax, (1, 2) is a sequence expression, whereas square brackets are used for distinct source constructs (including multiplicity ranges and the bracket expression form). Seeing [4] for an explicitly scalar return value suggests it may be a collection, and seeing [1, 2] does not preserve the source notation or distinguish the runtime sequence from other bracket constructs.

The question is about REPL result presentation, not a claim that the evaluated scalar or sequence has the wrong value. Could the output distinguish scalar values from sequence values, or document the brackets as a separate display notation? If the scalar call is intentionally returned as a one-item sequence, it would be helpful to explain why that differs from evaluating the same arithmetic directly.

Lingua principale
Go
Stelle
47
Fork
13
Merge medio
15h 52m
PR unite (30g)
906

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Open-MBEE/OpenSysML

Tutte le issue di Open-MBEE/OpenSysML

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.